This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 



BLACK BORDERS 

TEXT CUT OFF AT TOP, BOTTOM OR SIDES 
FADED TEXT 
ILLEGIBLE TEXT 
SKEWED/SLANTED IMAGES 
COLORED PHOTOS 

BLACK OR VERY BLACK AND WHITE DARK PHOTOS 
GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 

As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
28 February 2002 (28.02.2002) 




PCT 



(10) International Publication Number 

WO 02/17555 A2 



(51) International Patent Classification 7 : H04L 9/08 

(21) International Application Number: PCT/USO 1/25927 

(22) International Filing Date: 16 August 2001 (16.08.2001) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

60/226,429 
09/921,265 



18 August 2000 (18.08.2000) US 
1 August 2001 (01.08,2001) US 



(71) Applicant: VERISIGN, INC. [US/US]; 1350 Charleston 
Road, Mountain View, CA 94043 (US). 

(72) Inventor: FORD, Warwick; 6 Ellery Square, Cambridge, 
MA 02138 (US). 



(74) Agents: RADLO, Edward, J. et aL; Fenwick & West LLP, 
Two Palo Alto Square, Palo Alto, CA 94306 (US). 

(81) Designated States (national)*. AE, AG, AL, AM, AT, AU, 
AZ. BA, BB, BG, BR, BY. BZ, CA, CH, CN, CR, CU, CZ, 
DE, DK, DM, DZ, EE, ES, H, GB, GD, GE, GH, GM, HR, 
HU, ID, IL, IN, IS, JP, KB, KG, KP, KR, KZ, LC, LK, LR, 
LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, 
NO, NZ, PL, PT, RO, RU, SD, SB, SG, SI, SK, SL, TJ, TM, 
TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW. 

(84) Designated States (regional)*. ARIPO patent (GH, GM, 
KB, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, BS, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAH patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, 
TG). 

[Continued on next page] 



(54^ Titles COTT>n^Rir-;'^- , RHDI!>nTALS ror/^G 



o 



CLIENT 1 
» PRESENTS 
LOREDENTJALSJ 



' ENTIALS 
^HECKED^' 

PASS Y J 



CLIENT \ 
NOT I 
VALIDATEO ' 

Yz 

OlEM t PRESENTS PR OOF DATA ] ^ 



^33 



'SERVER\ FA,L 
5 CHECKS 
PROOF 
sPATA>\34 

PASS^ 



CLI Enin 

NOT 
VALIDATED 



T 



32 



SERVER 5 GENERATES UPDATE I „ 
DATA 53 AND NEW SECRET 54 h -37 



[SERVER 5 SENDS UPDATE DATA 53 TO CLIENT t H * 
JL ' 



CLIENT 1 REPLACES SUS 
50 WITH SECRET 54 J vii 



, „J 

[CLIENT \ SENDS ACKNOWLE'l 
[DGEMENT OATA TO SERVER 5^41 



SERVER 5 SET TO ACCEPT] 
OUTSTANDING SUS'S 
SINCE PREVIOUS 
VALIDATIONS NEW , 

SUS 54 _ J 




lOWLEDGEMENT^ VALIDATED 

YES r z 

SERVER 5 REPLACES SUS 



x 32 



50 WITH HEW.SUS 54 



CLIENT I VALJDATED "-44 



-40 



(57) A!»st**act: Systems, methods and computer readable 
media for enabling a server device (5) to validate one or 
more client devices (1). A shared unpredictable secret 
(50) is generated. The shared unpredictable secret (50) is 
stored in the client device (1) and in the server device (5). 
The client device (1) proves possession of a correct shared 
unpredictable secret (50) to the server device (5). The 
shared unpredictable secret (50) is replaced by a new shared 
unpredictable secret (54) each time the client device (1) is 
validated by the server device (5). 
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These and other more detailed and specific objects and 
features of the present invention are more fully disclosed in 
the following specification, reference being had to the 
accompanying drawings, in which: 
5 Figure 1 is a block system- level diagram of a. preferred 

embodiment of the present invention. 

Figure 2 is a flow diagram of a preferred embodiment of 
the registration/reset phase of the present invention. 

Figure 3 is a flow diagram of a preferred embodiment of 
10 the log- in phase of the present invention. 

Figure 4 is a flow diagram illustrating an alternative 
embodiment of the method illustrated in Figure 3. 

Figure 5 is an illustration of shared unpredictable secret 
50 and its progeny. 
15 Detailed Description of the Preferred Embodiments 

As used in the present patent application, ciient 
(sometimes referred to as "client device") 1 can be any digital 
dev-vca, o.cf„, u personal ccivrutcr, mobile phono, srw-vrtcar.-d.- 
Internet s.r-pl.i.^ce, or any cthe'x. network accessible devica . 
20 There may ><* one client 1 or, as illustrated in Figure 1, a 
finite number n of clients 1. Each client 1 wishes to 
communicate with an inf rastructural component that is referred 
to in the present patent application as a server (or "server 
device") 5. Server 5 may provide any type of service to. client 
25 1. For example, server 5 might be an Internet service provider 
or a telephone network access point. The communications link 
between client 1 and server 5 may be any link, such as a 
wireless link, a wired link, or a link over a network 4, which 
may be an open network such as the Internet. The process that 
30 commences with client 1 requesting validation with server 5 and 
including server 5. checking proof data that client 1 has 
generated from the shared unpredictable secret 50 is referred 
to herein as a "log-in". A log-in results in client 1 being 
either validated or not validated by server 5. 
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* One concern in such an environment pertains to credentials 
sharing. In this scenario, a person who has access to a client 
device 1 voluntarily shares his personal credentials, such as a 
password or private cryptographic key, with other user devices 

5 2 . All of these user devices 2 employ the user account of the 
original user. Two problems that arise from this scenario are: 
1) It is difficult for server 5 to hold particular users 2 

* accountable for their actions when using the services provided 
by server 5, since some or all users 2 are indistinguishable 

10 from each other; and 2) Users may fraudulently avoid paying 
subscription fees that are designed for payment on a per-user 
basis. 

Another concern is outright credentials theft. In this 
scenario, a nefarious person having access to a client-like 

15 device, referred to as "attacker 3" in Figure 1, penetrates a 

legitimate client device 1, copies stored credentials data from 
client device 1 into attacker device 3, perhaps supplements 
thi« thievery *ith * determination of other information such ar? 
Uie ufler 1 :-. 8 pr-'^.vord, pe^-csonal ici^utif iontiou number, or -o^io.I 

20 severity :a-»-=v : .om other sources, and then masquerades as the 

legitimate user from the attacker device 3. When the client 
device 1 being attacked is a hardware device and not a software 

' module, this scenario is sometimes referred to as "device 

cloning". Client devices 1 that are typically cloned include 

25 mobile telephones and smartcards. 

The present invention also applies to the copying of a 
portable credentials storage medium such as a magnetic stripe 
card or ticket if that medium is writable as well as readable 
by the terminal device in which it is used. In this case, the 

30 term client device 1 is taken to mean the combination of the 
portable credentials storage medium and the terminal device in 
which it is currently inserted. 

The present invention uses a method of stateful 
authenticators to provide a low cost, low overhead means of 

35 detecting when one user account is being employed for more than 
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At step 22, server 5 decides whether the authentication 
data presented by client 1 are acceptable- If not, client 1 is 
not allowed to register (step 26) . If acceptable, client 1 is 
allowed to register (step 23). In this eventuality, the shared 
5 unpredictable secret 50 is generated (step 24) • 

As illustrated in Figure 5, the shared unpredictable 
secret (SUS) 50 comprises an unpredictable component 51 and an 
optional fixed component 52. Unpredictable component 51 may be 
generated by a random number generator or a pseudo-random 
10 number generator. Typically, unpredictable component 51 is 

* generated at server 5 and communicated to client 1, but it may 
also be generated at client 1, or at a combination of server 5 
and client 1- As em alternative to communicating unpredictable 
component 51 to client 1, unpredictable component 51 may be 

15 pre-installed in client device 1 during manufacture or during a 
device 1 personalization process . 

1 When used, fixed component 52 typically comprises 
ide-atificcfixoii iiif oration. For simple, fixe,; .joiup'vaent 52 
mav be d. r-arial zuiifiboT of t"uc o3 i*?i*t d^vic-i !- Th;*-^ cou .d be 

20 useful v/Leu ther^ -.ir-": o or moro client devio-s 1 associated 
with the same user recount number. Conversely, fixed component 
52 could be the user account number when there is more than one 
user account number associated with the same client device 1 . 
This situation may occur, for example, when a user has one 

25 account number for business use and another account number fox- 
personal use; or when two users share the same cellular 
telephone 1; or when the client device 1 is a terminal into 
which users insert their credentials storage media. 

Typically, after server 5 has generated SUS 50, server 5 

30 transmits SUS 50 to client 1. The transmission is preferably 
encrypted, for reasons of security. Any type of encryption, 
including symmetric or asymmetric encryption, may be used. 

* Alternatively, an SUS 50 having an unpredictable component 51 
is generated by the aforementioned Dif f ie-Hellman key exchange 

35 technique, or pre-installed in device 1 as described 

5 
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subsequent log- in following the re-set of server 5 as described 
in conjunction with step 43, below. For purposes of 
simplifying this discussion, it will be assumed that the proof 
data are computed upon SUS 50-) It is desirable that SUS 50 
5 itself be not directly communicated over an open network 4 lest 
it be intercepted by a nefarious person. One method by which 
client 1 computes proof data without revealing SUS 50 itself is 
for client 1 to compute a one-way function of SUS 50 . The one- 
way function is typically a cryptographic hash function. Then, 

10 at step 34, server 5 checks the proof data by applying its 
(server 5's) proof data generation algorithm to its (server 
5's) stored version of SUS 50. If the proof data generated by 
server 5 matches the proof data presented by client 1, client 1 

• I has passed the test, and. the method proceeds to step 37. 

15 Otherwise, client 1 has failed the test and is not validated at 
step 32. Step 32 operates as previously described. 

In order for this method to work, client 1 and server 5 
have =:o b*-j uoing co^^i.-Jt^ufc if not id^xih^.c^l proo.»; c.ai,a 
generation algorithms . It is ina-v-.ter^ txl whether o---' r,ot an 

£0 eavesdropper knows what thia ^irjorithm is (or what these 
algorithms are) . 

At step 37, update data 53 and a new shared unpredictable 
secret 54 are generated, typically by sever 5. On Pig. 3 
(boxes 37 and 39) , item 54 is referred to as a "secret" rather 

25 than a "shared unpredictable secret", because the contents of 
the storage area that server 5 uses for SUS's are not replaced 
with new SUS 54 until step 40 is executed, below. Thus, the 
secret is not yet "shared". 

Then, at step 38, server 5 sends update data 53 to client 

30 1. Update data 53 is such that client 1 and server 5 are able 
to generate new SUS 54 from the most recent version of SUS 50, 
by means of applying update data 53 thereto. Typically, the 
step of applying update data 53 to SUS 50 comprises computing a 
one-way function of the combination of SUS 50 and update data 

35 53. For example, update data 53 could be a new random or 

7 
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has received the update data 53, but for some reason the ACK 
has been lost in transit, during the next log- in, client 1 at 

1 step 33 will be presenting proof data emanating from new SUS 

54, and server 5 at step 34 will be programmed to accept said 
5 data. If, on the other hand, update data 53 were not received 
by client 1, then, during the next log-in, client 1 at step 33 
will be presenting proof data emanating from an old SUS 50, and 
server 5 at step 34 will be programmed to accept said data. 

Step 42 illustrates the reality that server 5 may or may 

10 not receive the ACK, either because the update data 53 were 
lost in transit, the ACK was lost in transit, or the client 
device 1 failed. If server 5 receives the ACK within a 
preselected "time-out" period, then client 1 invalidated at 
step 44 and step 40 is entered into. At step 40, server 5 

15 updates its (server 5's) storage area that is allocated to 

■ SUS's with new secret 54. Thus, new secret 54 becomes a new • 
.j, shared unpredictable secret,, because it is now shared by client 
1 r^c\ server Z. As a sriubstsr^ to rV.ejg 4-, s^rv^r 5 dialer..-?* ol'/S 
50 aud any older SUS 1 s from Its Ll.::t oil acceptable S 1 b - 

20 Thus, in future log- in attempts, both client 1 and server 5 

will have stored therewithin new SUS 54; and 'che proof data (of 
client 1 in step 33 and server 5 in step 34) will be based upon 
new SUS 54 . 

If, on the other hand, server 5 does not receive at step 

•I 

25 42 the ACK from client 1 during the time-out period, client 1 
is not validated at step 32, which executes as described 
previously. 

The protocols described herein have the following 
desirable properties: 1) Any SUS (50) value produces no more 
30 than one validation; and 2) If the protocol fails at any stage, 

both client 1 and server 5 are left in a state that a new 
* invocation of the protocol will operate correctly. 

Optionally, for example in conjunction with step 34, 
server 5 maintains an audit trail -of log-in attempts, noting in 
35 particular those log-in attempts in which the step 34 checks 
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2) The attacker 3 logs in before legitimate client 1 logs- 
in again. In this case, attacker 3 can successfully masquerade 
as a legitimate user up to the time of the legitimate user's 
next log-in. On the legitimate user's next log-in, server 5 
5 will be alerted and special action taken. This special action 
might include out-of-band communication with the legitimate 
user, investigation of the situation, and consequent shut-out 
of attacker 3 from further validations. 

An alternative embodiment is illustrated in Figure 4. The 
10 method of claim 4 is identical to the method of Figure 3 

wherein acknowledgement data are used, except that steps 33 and 
34 are consolidated into steps 41 and 42. Thus, in the Figure 
4 embodiment, unlike the Figure 3 embodiment, the presentation 
of proof data by client 1 and the checking of the proof data by 
15 server 5 are not performed prior to server 5 generating update 
data 53 and new secret 54 in step 37. 

Step 50 of Figure 4 replaces step 41 of Figure 3. In step 
r»0 . cli'sr^t 1 so-Tic*.!* both the proof da ta and ti c* a cknowl edgemeiit 
rlrxhix to .^e;nrei Th* .• proci: d^.t- arc computed en r he ueiv 

20 secr*cii: . The proof data coul/.'i :cv.i: a dovnia role P"'->of 

,: s data and acknowledgement data. Iu this case, there ie n.a ueed 
for acknowledgement data separate and apart from the proof 
data. 

Step 51 of Figure 4 replaces step 42 of Figure 3. In step 
25 51, server 5 checks both the proof data and the acknowledgement 
data, or, in the case where the proof data serve the double 
role as proof data and acknowledgement data, the proof data. 

As stated previously, there may be legitimate use of a 
number n of different client devices 1 by a single legitimate 
30 user. In this case, server 5 holds current SUS's 50 and new 
SUS ! s 54 for each client device 1, and considers each client 
device l to be legitimate; and each client device 1 has its own 
unique SUS 50 and new SUS 54. The number n of clients 1 may be 
restricted in accordance with local policy. In this scenario, 
35 SUS's 50, 54 are respectively unique from one device 1 to the 

IS 
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Claims 

* 1. A method for validating a client device by a server 

device, said method comprising the steps of: 

generating a shared unpredictable secret; 
5 storing the shared unpredictable secret in the client 

device and in the server device; 
requiring the client device to prove that it holds a 
correct secret as a precondition to the server 
h device validating the client device; and 

10 replacing the shared unpredictable secret by a new 

shared unpredictable secret when the server device 
validates the client device. 
2. The method of claim 1 wherein an initial shared 
unpredictable secret is determined in the client device and in 
15 the server device during a registration step that occurs prior 
to a log- in step. 

3.. The method of claim 2 wherein the registration step 
enrailr? vuoro cheeking of. bona f i.dc-s of the cl ient: device than 
d^rs '? ioa -*in *tep- 
20 4. rhe method of claim 2 wherein, during the registration 

step, the client device is required to make a payment to the 
user device. 

5 . The method of claim 1 wherein the shared unpredictable 
secret is generated by a generator from the group comprising a 

25 random number generator and a pseudo- random number generator. 

6. The method of claim 1 wherein the shared unpredictable 
secret comprises an unpredictable component and a fixed 
component . 

7. The method of claim 1 wherein a plurality of client 
30 devices desire to be validated by the server device; and 

each client device has a unique unpredictable secret 
that it shares with the server device. 

8. The method of claim 1 wherein, following a validation 
of the client device, the server device discards the original 

35 shared unpredictable secret and stores within the server device 

13. 
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the server device is adapted to accept from the 
client device any proof data that are generated 
from a secret that is newer than the secret for 
which the most recent acknowledgment data have 
5 been received by the server device. 

14. The method of claim 11 wherein: 

the client device sends to the server device both the 
acknowledgment data and proof data derived from 
the new secret. 
10 15. The method of claim 14 wherein: 

the proof data are computed on the new secret; and 
the proof data serve also as acknowledgment data. 
h 16. The method of claim 1 wherein: 

the client device presents proof data to the server 
15 device, wherein the proof data are derived from a 

shared unpredic table secret using a proof data 
generation algorithm, and the proof data do not 
«:S i vu'J cjp. the ybared v^predJLc table aceret ; 
the ;jorve>; device che-_\u the prcoi data Ly u:j.xixcj a 
20 proof data gcitr.cation alyo';:ithm consistent with 

the proof data generation algorithm used by the 
client device; and 
when the server device determines that the proof data 
presented by the client device were not generated 
25 from the same shared unpredictable secret that is 

stored in both the client device and in the server 
device, the server device does not validate the 
client device. 

17. The method of claim 16 wherein each proof data 
30 generation algorithm is a one-way function. 

18. A system for enabling a server device to validate a 
client device, said system comprising: 

at least one client device; 
a server device; 
Is a shared unpredictable secret; 

15 



WO 02/17555 



PCT/US01/25927 



1/5 




-1(1) 




-1(2) 



GHENT 



SHARING 
USER 
DEVICE 



•2 




FIG.1 



i J 




•NETWORK 4 



SUBSTITUTE SHEET {RULE 26) 



WO 02/17555 



PCT/US01/25927 



3/5 



f CLIENT 1 
i ' PRESENTS 
! CREDENTIALS 




PTIALS 
{KECKED^ 

PASS V 




I CLIENT j PRESENTS PROOF DATA L 

i "^33 



^ERVER\£ A,L 
5 CHECKS 
PROOF 
J)ATA/\34 

PASS 



32 



I SERVER 5 GENERATES UPDATE | ' 

| DATA 53 AMO HEW SECRET 5 4 J- 3 7 



[SERVE ? SEaDS UPDATE DATA 53 TO CLlEifM H 8 



3 



CLIENT 1 REPLACES SUS 
50 WITH SECRET 54 fa fl 
I 

["CLIENT 1 SENDS ACKNOWLE? 
ID GEMENT DAT A TO SERVER 5 t 41 



SERVER 5 SET TO ACCEPT] 
OUTSTANDING SUS'S . 
SINCE PREVIOUS 
VALIDATION.PLUSNEW 

SUS 54 J 



FIG.3 



. SERVER , 
^'5 RECEIVES ACK- 
< JOWLEDGEMENT 
>^.J)ATA ^< 42 

YES • . " 



43 





SERVER 5 REPLACES SUS 
50 WITH NEW SUS 54 



"client < WOtI 

VALIDATED J 
X 32 

•40 



CLIENT \ VALIDATED N 4 



SUBSTITUTE SHEET (RULE 26) 



WO 02/17555 



PCT/US01/25927 



5/5 



FIG.5 



51 



1 



UNPREDICTABLE 
COMPONENT 


FIXED 1 
COMPONENT 1 


50 


* 



NEW SHARED 
UNPREDICTABLE 
' SECRET 




SUBSTITUTE SHEET (RULE 26) 



